In Self-Organizing Networks (SON), most SON Functions work with their closed control loops, which react to certain dedicated Key Performance Indicators (KPIs)/counters of the network by updating the Network Configuration Parameters (NCP). The concept of SON Objective Manager and its Objective Model, Context Model, and Function Model is described e.g. in WO 2014/191469 A1. For example, a KPI may include a call drop rate, a handover success rate and/or a cell load. In general, a KPI may be calculated from one or more counters, and may also depend e.g. on other parameters detected at the network such as a fault status. A network configuration parameter may be e.g. a base station transmission power, a cell individual offset, a handover hysteresis, a time-to-trigger etc. Operator objectives are business policies, and/or strategic policies, and/or technical policies that may include conditions and/or that may include priorities. A context may describe the conditions which have to be fulfilled in order to apply a certain function model. Example parameters of a context are a time of the day, a weekday, a fault status of the network or a network element, a traffic load of the network or a network element, or an arbitrary combination thereof. A SON Function Model is related to an operator objective and includes at least one SON-Function Configuration Parameter Value may include at least one condition.
The earlier solution can be described with its three models and its mapping principle. Its three major models may be summarized as follows:                1. The Context Model provides a description of the context properties that can be used in the condition part of the objective rules. The Context Model may have the following general form:        
{contextProperty1 HAS DOMAIN [propertyValuesMargin1],contextProperty2 HAS DOMAIN [propertyValuesMargin2],...,contextPropertyn HAS DOMAIN [propertyValuesMarginn]}                2. The Objective Model represents what an operator would like its SON network to achieve. The Objective Model has the following general form:        
{IF condition1 THEN objective1 (e.g., KPI target1) WITH precedence1IF condition2 THEN objective2 (e.g., KPI target2) WITH precedence2...,}                3. A SON Function Model is responsible for encoding a functional description of a specific SON function. It has the following general form:        
{SON Function Objective1: SCVSet1SONFunctioni Objective2: SCVSet2SONFunctioni ...    : ... Objectiven: SCVSetnSONFunctioni...}
That is, a SONFunction (SONFunction i) may attempt to achieve one or more (n) objectives. For each (say Objectivej) of the objectives, a particular SCV (SCVSetj) for this SONFunction is defined.
Its principle of mapping operator objectives into SON-function specific configurations may be summarized as shown in FIG. 1, taken from WO2014/191469.
FIG. 1 shows a functional architecture of SON Management with the function and interfaces of the SON Objective Manager, that provides methods and interfaces to automatically interconnect the operator objectives (for example, business, strategic and technical objectives) of the mobile network operator with the model descriptions of the SON functions deployed in the network, such that as the outcome of this interconnection process SCV Sets (which are, for example, configuration values and/or policies) for the SON Functions are generated that configure the SON Functions in such way that the operator objectives are met by the SON system.
In FIG. 1, a functional architecture of SON Management including the SON Objective Manager is shown. The SON Objective Manager itself is depicted as a rectangular box. The interfaces of the SON Objective Manager (which are explained in detail below) are depicted as pentagonal boxes. The data serving as input to the SON Objective Manager (Operator Objectives and SON Function Models), as well as the data provided as output by the SON Objective Manager (SCV Sets or Policies), are depicted as round-edge rectangular boxes. Furthermore, FIG. 1 shows two exemplary SON Functions which are also depicted as rectangular boxes. The SCPs of these SON Functions are depicted as circles. The arrows in FIG. 1 depict the data flow between the components of the SON Management.
Features of the SON Management architecture are for example:                The SON Function Model Interface may define the access to a machine understandable model of the behavior of each SON Function. Hence, the interface may provide access to information about how different SCV Sets of a specific SON Function satisfy possible operator objectives. The SON Function model that is accessed through the interface may be usually provided by the vendor of the SON Function. In order to enable the usage of SON Functions from different vendors, the SON Function Model Interface may be standardized in such a way that the SON Objective Manager can configure SON Functions from different vendors.        The Operator Objective Interface may define a standardized syntax for the description of operator objectives. The description of the operator objectives may be thereby coherent with the description of the operator objectives in the SON Function Model Interface, to enable the mapping between the objectives and the model.        
Therefore, also the Operator Objective Interface may be standardized to ensure multi-vendor capabilities of the SON Objective Manager.                The SON Objective Manager may take the operator objectives and the technical description of each SON Function, may perform a reasoning process, and may determine a SCV Set for each SON Function. Since the SON Function Model Interface could also be standardized, thus the SON Objective Manager may create SCV Sets for SON Functions from different vendors. This may facilitate a high-level integration of multi-vendor SON Functions controlled by common operator objectives.        
The SON Function Interface may describe the interconnection between the SON Objective Manager and the SON Functions. The SCV Sets as created by the SON Objective Manager may be provided to the SON Functions. Depending on the implementation the SCV Sets may include dedicated configuration settings for the SON Function, or may include a policy. In the context of the present application, the term “policy” is used for both “policy” and “configuration settings”, unless otherwise indicated or made clear from the context. Furthermore, depending on the implementation of the SON Objective Manager, the SON Function Interface may be standardized. The SCV Sets of the SON Functions may be automatically adjusted based on the operator objectives.
Components used for the present approach, for example a SON Function Model Interface, an Operator Objective Interface, the SON Objective Manager, and a SON Function Interface, may be implemented in different ways.